home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄22⁄91 / 3027-MA3 opinion,for what-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.3 KB  |  81 lines  |  [TEXT/GEOL]
  1. Item    3039537                         20-Feb-91        08:49PST
  2.  
  3. From:   SATORI                          Satori SW, Hugh Rogovy,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    MA3 opinion,for what its worth
  10.  
  11. Ok, Ok, I can't just sit here and watch anymore...
  12.  
  13. Speaking as a commercial developer (as opposed to an in-house, educational or
  14. contract programmer) AND a non-C++ programmer, I think the shift to C++ is
  15. basically irrelevant. The shift to MacApp 3.0 (regardless of language) is the
  16. more problematic issue for me.
  17.  
  18. We need some of the language features C++ offers today that OP does not. Pascal
  19. 9x is an initial/unfinished specification, NOT a tool that will let me get any
  20. software development done today.  There is no guarantee that it will ever see
  21. the light of day and even less chance that it will be available soon on other
  22. platforms.  I'm tired of programming in a exiled language.
  23.  
  24. I would think that that any competent OP programmer who puts forth a small
  25. amount of effort would be able to make the syntax transition to C++ (use the
  26. time you currently are using to rag on C++ to learn it!!!). The language just
  27. isn't the issue here.  What we(I) really need a guarantee that MacApp is going
  28. to become design-stable (or painlessly updatable) someday.  We wrote an app in
  29. MacApp 1.1 back in 1988. Three years later, it's still written in MA 1.1
  30. because after more than a few weeks of getting nowhere quickly,  we gave up on
  31. a conversion to MacApp 2.0bx.  For two years, we've been planning to completely
  32. rewrite it in MA 2.0 when "we can find the time" (we still haven't found
  33. it)...not because a MA 2.0 version will make it a better product, but because
  34. maintenance is becoming a nightmare.  Am I going to find myself in the same
  35. situation going from 2.0 to 3.0 with the three apps we have written in 2.0?
  36.  
  37. We need faster compile/link turnaround times.  I generally use two editors and
  38. attempt to code while I'm waiting for builds. Quicker tools would eliminate
  39. this and let me stay focused on one section of code at a time.
  40.  
  41. I think James is probably correct in believing that MA will eventually end up
  42. in ROM (in some small convoluted form).  But, a no-source version of MA is not
  43. something I want to see soon (or later).  I still haven't seen a shipping
  44. version of MA 2.0 final with the Technote #280 bugs-fixed.  I don't have time
  45. to wait for Apple to update the software that all of my company's development
  46. efforts depend upon.  I need to be able to correct MA problems in my apps as
  47. soon as I realize them.  A true black-box object library would be a really cool
  48. thing from an academic point of view.  But, I program in a commercial
  49. environment in which I create software mainly to make $ for this company, not
  50. an academic one.  Anything that hinders that effort (unavailability of source
  51. code can many times be a hindrance) costs us money.  It is true that source
  52. code for the toolbox is not available, but the toolbox wasn't followed by a
  53. 42-page bug report, either.  I don't mean that as a slight to the MA team, they
  54. HAVE done incredible things.  It's just that a general-use, object-oriented
  55. application framework is far more complex and difficult to tame than a
  56. collection of procedurally written ROM routines.  It's going to be a long time
  57. before we can even begin to consider a no-source version of MA.
  58.  
  59. Don't fight the shift to C++.  Take advantage of the portability and language
  60. feature gains...or...if you love OP, just become a C++ reader and remain an
  61. Object Pascal coder.  I think we can all handle that much.  Like it or not, C++
  62. is becoming prevalent in the software engineering world (read through the ads
  63. in any PC programmers journal).  Apple needs to move into the mainstream both
  64. with its' machines and its' development tools.  Windows apps are/will be
  65. written in C or C++, isn't it obvious that Apple would benefit by simplifying
  66. the Windows to Mac porting process.
  67.  
  68. Put your efforts and voices toward helping Apple to get MacApp feature-stable
  69. (or painlessly updatable) and bug free.  Forget about the language
  70. wars...language choice is basically a meaningless issue.
  71.  
  72. Apple, ship C++ MacApp 3.0.  But from now on, quit pulling the rug out from
  73. under us with each MA version change.
  74.  
  75.  
  76. Chris 'sorry for the rambling style of writing' Le Croy
  77.  
  78.  
  79.  
  80.  
  81.